Machine Translated Scrapbox Published in Quartz on 2024-11-24

Automatic English translation from Scrapbox (Cosense) is now running on GitHub Action.

But after translation, importing into Scrapbox is rubbing me the wrong way.

Sometimes this happens, but it's inexplicable, and it's kind of a pain in the ass now - I'm not going to import it into Scrapbox.

Why don't we combine this and do "Scrapbox -> JSON -> English translation of JSON -> Markdown -> publish in Quartz"? I'm thinking.

Let's do a little research first.

I'll give it a shot anyway.

│ Empty Quartz

│ ● Treat links as shortest path ((default))

│ ○ Treat links as absolute path

│ ○ Treat links as relative paths

Hmmm, let's leave it at default.

$ npx quartz build --serve

Motion made.

Next survey

I've written a lot of stuff and even have uncommitted edits.

What's the situation here?

Even then, Quartz looks v4.

On the other hand, back then it was Scrapbox, not Cosense.

Quartz

This branch is 3 commits ahead of, 564 commits behind jackyzha0/quartz:v4

Chaos because content updates are also in the same repository!

$ git pull --rebase upstream v4

CONFLICT (content): Merge conflict in package-lock.json

There are 564 commits, so I'm not sure what the big picture is.

Are there separate updates for my repository and upstream?

Oh no, I've lost my mind. I can't do it.

https://gyazo.com/1102064e16a17999b6f8209610718784

Using GitHub Action as a free serverless execution environment, I've done it with Omoikane Embed and others, and it's useful, but Git wasn't designed for that purpose.

Upstream OSS is naturally updated.

Let's rename this repository and start anew.

Uh, maybe not.

GitHub's restriction that multiple forks cannot be done from the same repository.

Can I do it if I archive it? →I can't do it.

I guess I'll have to turn it off.

clone and then DELETE what you have RENAMED

exclamation of relief or disappointment

I want to avoid putting content here in the future.

I would like to say that this is a component and not a content holder.

% git submodule add git@github.com:nishio/quartz.git quartz

% git clone --depth 1 git@github.com:nishio/etude-github-actions.git

I thought it would be faster if I just took the latest, but it's so slow.

I'm getting tired, so I'm going to take a bath first.

For now, let's run it once before automating.

You did some minor experimental work on this last time.

code:tmp_1.sh

cp etude-github-actions/nishio/data_en_prev.json nishio.json

tasks/json_to_markdown/run.sh

quartzPages was created.

See this from quartz

$ npx quartz create

code::

│ ● Empty Quartz

│ ○ Copy an existing folder

│ ○ Symlink an existing folder

So we can just symlink it here.

code::

2 | title: '"I can\'t shake it" and "I won\'t shake ...

---------------------^

code::

Parsed 20937 Markdown files in 6m

Filtered out 0 files in 4ms

Done processing 20937 files in 11m

hint: exit with ctrl+c

https://gyazo.com/b992ca4584829022573d3af2cd92f756

sound effect for shock (usu. the disappointing kind)

Oh, is that the one where the line becomes an object when metadata is attached to the Scrapbpx export?

Can we use the Github Wiki as a comment form?

Would you like to ask a question or point out an error in an article on Github Issues?

I see

I was thinking of making it possible to send information "I want this page to be improved" when the quality of the English translation is not good enough, but I was thinking of using Issues.

code::

at decodeURI (<anonymous>)

at transformInternalLink (../util/path.ts:89:38)

at transformLink (../util/path.ts:207:20)

at ../plugins/transformers/links.ts:104:49

I don't know how to fix it without a little more detail.

Oh, no!

Are there countless cases of base64-encoded URLs being corrupted in the translation process?

I was dismayed to think there would be countless of them, but surprisingly, I was able to get down to three.

I could see it locally.

If you publish this on GitHub Pages, you can publish it.

I'm thinking the quality of the translation is not so good.

But that's okay because it's still not good enough.

If you try to automate the publishing process, the above error must be resolved automatically.

Fundamentally, links should be judged as links and then only the title portion should be translated.

This is designed to push to GitHub when synced, so the contents will be placed in this repository

Code and content managed in one place

That's what happens when you offer something for people who don't know much about it, and in fact I did that with omoikane-embed and others.

but not good in the long run because updates to the code are masked by updates to the content.

This is also a GitHub Action that builds when updated, with code and content in bulk management.

public/ is created when build is done.

https://gyazo.com/f59f0cc8bc96cd087190a2720c10aca2

I think we had the same conversation last time.

I've already commented out Component.Explorer and Component.TableOfContents.

Component.Graph?

Component.Search may be

Result of stopping Component.Graph

54.58GB

Result of stopping Component.Search

not much different

There is a huge script tag under BODY.

I feel like I can't do anything about this.

Quartz 4.0 has a huge script tag at the end of the static HTML, 2.5MB per page. 20,000 pages is about 50GB, which is a problem. I searched GitHub Issues to see if there is a solution to this problem.

Main Causes

This is due to the recent update that added support for Mermaid.js, which allows JavaScript to be embedded directly in HTML files.

solution

Disabling Mermaid: You can disable Mermaid.js by changing the following settings in quartz.config.ts.

There have been reports of build sizes returning to normal simply by disabling Mermaid, which is the easiest solution currently available.

Deploy the public part of the build result in a separate repository.

I got it.

Why this is showing up in the backlinks to this is a mystery to me.

It's kind of subtle...

---